Hi Russ,
Sorry you are having problems.
Strange. One possibility might be a limit switch (noise) or following error fault might cause a halt and an invalid error message. But I thought our later Versions reported such things correctly. Run KMotion.exe while running the Job and watch the Console Screen for messages.
Otherwise please post some GCode (preferably simple) that causes the error and also post your Trajectory Planner Settings. Too small of a Facet Angle setting can be a problem. Set to 1 degree or larger. Are you running KMotionCNC or Mach3?
The TeachMotion.exe example can be run from the \KMotion\Release directory and it has a button to check the USB speed of your PC.
Regards TK
| Group: DynoMotion |
Message: 10623 |
From: Russ Larson |
Date: 12/2/2014 |
| Subject: Re: Kflop starving |
TK, It is certainly possible this is a noise issue, the limit switches are at 5v and come into a 5V tolerant input on Kflop. We might try and add a relay and bump this up to 12 VDC well above most noise concerns. We also did exactly as you suggested, here are a few more hints that might help pin point this issue. When watching the console screen while running the program using the MACH3 plugin everything appears to be working perfect. Suddenly for no reason the destination comes up to some huge negative number, the G code is asking for a .1" move and then we get the starve error or also the missed step error. You can run it again and this might happen again and sometimes in the exact same spot. We can then turn down the feed rate run it again and it will go right by this with no issue at all. Next hint, while running suddenly the Mach3 screen that shows how much time has elapsed on the job will suddenly be wrong and start showing weird times. Again, nothing else is running on this PC with Windows XP. The only software on this machine is Mach3 and Kmotion. The job is doing a very simple center line vcarve engraving. The characters are not too small about 1/2" tall. Again, not a typical vcarve where the tool is adjusting Z to control the width of the cut. These are simple center line cutting at the same depth. We also tried to load a beta driver some time ago that was suppose to address buffer starve issues, but that would never install so we are using the standard driver and plugin in the release. We could post some Gcode, but this does not seem to be the gcode as it happens on many different programs. In some ways that does seem to point to noise, we could totally disable the limit switch and wire it directly on the kflop or disable limits. We can run some programs for hours with no issues, so this has been difficult to narrow down exactly what is the root cause of the issue. Really appreciate all your help and feedback. Russ Larson From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, December 02, 2014 1:37 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Kflop starving Sorry you are having problems. Strange. One possibility might be a limit switch (noise) or following error fault might cause a halt and an invalid error message. But I thought our later Versions reported such things correctly. Run KMotion.exe while running the Job and watch the Console Screen for messages. Otherwise please post some GCode (preferably simple) that causes the error and also post your Trajectory Planner Settings. Too small of a Facet Angle setting can be a problem. Set to 1 degree or larger. Are you running KMotionCNC or Mach3? The TeachMotion.exe example can be run from the \KMotion\Release directory and it has a button to check the USB speed of your PC.
We are using a version of kmotion about three weeks old, do not have the version handy right now. The issue we are seeing is we keep getting buffer starved errors. The task manager in windows is showing the CPU is 90% or more idle. We have tried several things, including reducing the feed rate drastically. You can cut the exact same part and sometimes it gets all the way through without an issue, the next time you run it will get the buffer starved error. We have also changed the length of the buffer, but can't go too big or it will take 10 seconds or more to see a pause. Any ideas of what else we can look at this is very frustrating. |
|
| Group: DynoMotion |
Message: 10625 |
From: Tom Kerekes |
Date: 12/2/2014 |
| Subject: Re: Kflop starving |
Hi Russ,
Regarding 5V inputs. We prefer you keep the Input voltages to KFLOP below 3.8V otherwise there is a possibility of a lot of clamping current. I doubt if this is related to the current the problem. You might also add filter capacitors (ie 0.1 uF ceramic caps to KFLOP GND) near KFLOP to filter noise. But if Noise on the Limits is the problem then there should be a message on the KFLOP Console Screen.
You might also observe the KMotion Axis Screen's Destination Values to see if there are also huge values.
I'm not aware of any problem of that sort with V4.32 and the later test versions do not seem to have any related fixes. The Plugin Version should match the version of KMotion that is installed. Do you have multiple Versions of KMotion installed on the PC?
What Version of Mach3 are you using? Please Post your Mach3 XML file.
Regards TK
| Group: DynoMotion |
Message: 10626 |
From: Russ Larson |
Date: 12/2/2014 |
| Subject: Re: Kflop starving |
TK, The KFLOP input do have .1uF caps on them right at the KFLOP. As I shared when this thing crashes the destination register in KMOTION show huge values many times huge negative numbers. No we have only one version installed will get the number it was out about a week before Thanksgiving as I recall. We are using one of the last versions of release MACH3, R3.043.066 as I recall. I know the plugin is a match and kmotion is also a match of what is loaded in KFLOP. We never get any limit errors on the console unless we actually hit limits and then they do print out on the console and show up in MACH3. We can add a relay for limits have the switches drive a 12VDC relay, and the contacts would drive KFLOP input and even do it with 3.3 volts generated on board. Something tells me this is not the limits, because we could run the same program and have it stop at the same exact spot a few times reduce feedrate and run it again and it would fly past that spot. Again, we are cutting nothing complex at all, just simple engraving some letters. I can get you the exact versions of everything right after work this evening. Thanks Russ Larson From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, December 02, 2014 3:40 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Kflop starving Regarding 5V inputs. We prefer you keep the Input voltages to KFLOP below 3.8V otherwise there is a possibility of a lot of clamping current. I doubt if this is related to the current the problem. You might also add filter capacitors (ie 0.1 uF ceramic caps to KFLOP GND) near KFLOP to filter noise. But if Noise on the Limits is the problem then there should be a message on the KFLOP Console Screen. You might also observe the KMotion Axis Screen's Destination Values to see if there are also huge values.
I'm not aware of any problem of that sort with V4.32 and the later test versions do not seem to have any related fixes. The Plugin Version should match the version of KMotion that is installed. Do you have multiple Versions of KMotion installed on the PC?
What Version of Mach3 are you using? Please Post your Mach3 XML file.
It is certainly possible this is a noise issue, the limit switches are at 5v and come into a 5V tolerant input on Kflop. We might try and add a relay and bump this up to 12 VDC well above most noise concerns. We also did exactly as you suggested, here are a few more hints that might help pin point this issue. When watching the console screen while running the program using the MACH3 plugin everything appears to be working perfect. Suddenly for no reason the destination comes up to some huge negative number, the G code is asking for a .1" move and then we get the starve error or also the missed step error. You can run it again and this might happen again and sometimes in the exact same spot. We can then turn down the feed rate run it again and it will go right by this with no issue at all. Next hint, while running suddenly the Mach3 screen that shows how much time has elapsed on the job will suddenly be wrong and start showing weird times. Again, nothing else is running on this PC with Windows XP. The only software on this machine is Mach3 and Kmotion. The job is doing a very simple center line vcarve engraving. The characters are not too small about 1/2" tall. Again, not a typical vcarve where the tool is adjusting Z to control the width of the cut. These are simple center line cutting at the same depth. We also tried to load a beta driver some time ago that was suppose to address buffer starve issues, but that would never install so we are using the standard driver and plugin in the release. We could post some Gcode, but this does not seem to be the gcode as it happens on many different programs. In some ways that does seem to point to noise, we could totally disable the limit switch and wire it directly on the kflop or disable limits. We can run some programs for hours with no issues, so this has been difficult to narrow down exactly what is the root cause of the issue. Really appreciate all your help and feedback. Sorry you are having problems. Strange. One possibility might be a limit switch (noise) or following error fault might cause a halt and an invalid error message. But I thought our later Versions reported such things correctly. Run KMotion.exe while running the Job and watch the Console Screen for messages. Otherwise please post some GCode (preferably simple) that causes the error and also post your Trajectory Planner Settings. Too small of a Facet Angle setting can be a problem. Set to 1 degree or larger. Are you running KMotionCNC or Mach3? The TeachMotion.exe example can be run from the \KMotion\Release directory and it has a button to check the USB speed of your PC. We are using a version of kmotion about three weeks old, do not have the version handy right now. The issue we are seeing is we keep getting buffer starved errors. The task manager in windows is showing the CPU is 90% or more idle. We have tried several things, including reducing the feed rate drastically. You can cut the exact same part and sometimes it gets all the way through without an issue, the next time you run it will get the buffer starved error. We have also changed the length of the buffer, but can't go too big or it will take 10 seconds or more to see a pause. Any ideas of what else we can look at this is very frustrating. |
|
| Group: DynoMotion |
Message: 10637 |
From: Russ Larson |
Date: 12/4/2014 |
| Subject: Kflop starving |
TK, Attached is the XML you requested from MACH3. We are currently using R3.043.022. We are using V4.32 of Kmotion. Last night we ran the exact same program file and it ran from beginning to end without an error. We even created some Gcode cutting a circle at 100 IPM to see if we could get the starve error and nothing happened. Now another interesting observation. We decided to run an experiment with the circle file programmed with a feed rate of 100 IPM. We could see on the Mach3 screen it never got to 100 IPM, probably driven by the fact the direction is almost constantly changing in a circle. It got to maybe 45 IPM, but never gave an error. Then we decided to run the exact same file with KmotionCNC directly. This also ran perfect but much faster probably 75-80 IPM, which was surprising. Is there that much overhead in processing the messages from MACH3 when it is doing the trajectory planning? The bizarre part is if you look at the CPU utilization on the 3GHz Dual Core processor it is almost nothing, it is idle about 94% of the time. The one feature we love in KmotionCNC is if you hit PAUSE it stops instantly, unlike when the plugin for Mach3 is being used. We understand what drives this, but sad they could not provide a better linkage for Kmotion to control that aspect better. We see the latest version of Kmotion is 4.33J, dated November 10th. Do you think that version would address the strange things we have been seeing? Thanks for all your help. Russ Larson
|
|
|
@@attachment@@
|
| Group: DynoMotion |
Message: 10647 |
From: Tom Kerekes |
Date: 12/5/2014 |
| Subject: Re: Kflop starving [1 Attachment] |
Hi Russ,
I'm unable to reproduce a Buffer Starve with your XML and Mach Rev 3.043.066 and our latest Test Version. You might try this Version of Mach3.
I think running slow has to do with the Trajectory Planning in Mach3 not anything to do with overhead in processing messages. We just do what Mach3 tells us to do.
Regarding PAUSE: It is possible to do an instant hardware Feedhold with Mach3. But you need to add an external button to KFLOP or a New Screen Button in Mach3 to send a NotifyPlugins message to KFLOP to do the hardware feedhold. Mach3 will not be aware of this and think the GCode is just running really slow. So from its perspective the job is still running so you can not do things like Jog or change offsets without hitting Stop First.
Regards
TK
| Group: DynoMotion |
Message: 10651 |
From: Russ Larson |
Date: 12/5/2014 |
| Subject: Re: Kflop starving |
TK, Thanks for your comments, we will upgrade to all the latest versions and give it a try. I also like you idea of the notifyplugins message to KFLOP to do a hardware feedhold. This is going to be high on our list for safety improvements, the three second delay has made us very nervous when cutting 1" aluminum, they don't give that stuff away. LOL Russ From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Friday, December 05, 2014 2:12 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Kflop starving I'm unable to reproduce a Buffer Starve with your XML and Mach Rev 3.043.066 and our latest Test Version. You might try this Version of Mach3. I think running slow has to do with the Trajectory Planning in Mach3 not anything to do with overhead in processing messages. We just do what Mach3 tells us to do. Regarding PAUSE: It is possible to do an instant hardware Feedhold with Mach3. But you need to add an external button to KFLOP or a New Screen Button in Mach3 to send a NotifyPlugins message to KFLOP to do the hardware feedhold. Mach3 will not be aware of this and think the GCode is just running really slow. So from its perspective the job is still running so you can not do things like Jog or change offsets without hitting Stop First. [Attachment(s) from Russ Larson included below] Attached is the XML you requested from MACH3. We are currently using R3.043.022. We are using V4.32 of Kmotion. Last night we ran the exact same program file and it ran from beginning to end without an error. We even created some Gcode cutting a circle at 100 IPM to see if we could get the starve error and nothing happened. Now another interesting observation. We decided to run an experiment with the circle file programmed with a feed rate of 100 IPM. We could see on the Mach3 screen it never got to 100 IPM, probably driven by the fact the direction is almost constantly changing in a circle. It got to maybe 45 IPM, but never gave an error. Then we decided to run the exact same file with KmotionCNC directly. This also ran perfect but much faster probably 75-80 IPM, which was surprising. Is there that much overhead in processing the messages from MACH3 when it is doing the trajectory planning? The bizarre part is if you look at the CPU utilization on the 3GHz Dual Core processor it is almost nothing, it is idle about 94% of the time. The one feature we love in KmotionCNC is if you hit PAUSE it stops instantly, unlike when the plugin for Mach3 is being used. We understand what drives this, but sad they could not provide a better linkage for Kmotion to control that aspect better. We see the latest version of Kmotion is 4.33J, dated November 10th. Do you think that version would address the strange things we have been seeing? Thanks for all your help. |
|
| | | | | |
